home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20021006-20030409 / 000318_fdc@columbia.edu_Mon Feb 17 18:31:10 EST 2003.msg < prev    next >
Text File  |  2020-01-01  |  5KB  |  128 lines
  1. Article: 14114 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: Running multiple kermit scripts on one connection
  6. Date: 17 Feb 2003 18:31:01 -0500
  7. Organization: Columbia University
  8. Lines: 111
  9. Message-ID: <b2rrbl$ks3$1@watsol.cc.columbia.edu>
  10. References: <775a2ab0.0302171458.f8f21f9@posting.google.com>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1045524663 17337 128.59.39.139 (17 Feb 2003 23:31:03 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 17 Feb 2003 23:31:03 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14114
  16.  
  17. In article <775a2ab0.0302171458.f8f21f9@posting.google.com>,
  18. Minty <metceed@yahoo.com> wrote:
  19. : I'm trying to run multiple kermit scripts over one dial-up connection.
  20. : More specifically:
  21. : 
  22. : I am writing a program that will automatically send an alert. One the
  23. : the ways it sends an alert is via an sms message. I have an account
  24. : with an pstn-to-sms gateway provider. So I can dial-up this gateway
  25. : modem, and using the TAP protocol, I can send sms messages.
  26. : 
  27. : What I want to do is control, within my program, the 2 main aspects of
  28. : the sending process. The 'loggin on' part, and the 'sending messages
  29. : part'. I already have a kermit script that does both. I want to
  30. : seperate those to parts and call them seperately from my program. The
  31. : reason is that there could be many messages going out for the one
  32. : connection. This is decided at run-time. Another reason is so that the
  33. : program can know which alerts got sent and which didn't.
  34. : 
  35. : So, if for example I'm sending out 2 alerts, the steps would be as
  36. : follows:
  37. : 
  38. : 1-The program would run a kermit script, that opens connection from
  39. : local pc to local modem, dials the gateway modem and logs on, as per
  40. : the TAP protocol. The script would be called with the gateway provider
  41. : number as parameter.
  42. : 
  43. : 2-Then the program would run another kermit script, that sends
  44. : messages as per TAP protocol, with the message and sms number as
  45. : parameters, noting the exit code.
  46. : 
  47. : 3-It would again call the same send script with another message and
  48. : another number as parameter, again noting the exit code.
  49. : 
  50. : 4-It calls another scipt, that logs off the connection to the gateway
  51. : modem, and also closes connection from local pc to local modem.
  52. : 
  53. : Now, the problem I have noted with running multiple kermit scripts, is
  54. : that at the end of running one script, it closes the connection to the
  55. : gateway modem and also the connection from the local pc to the local
  56. : modem.
  57. : 
  58. : I'm using the latest kermit 95 version on a Windows 2000 machine. 
  59. : 
  60. : Anyone have any ideas on how I could do this? I'm sure it's only a
  61. : setting I would have to set with kermit, but I haven't found it.
  62. : 
  63. : One idea I did try was to manually open an instance of kermit and open
  64. : connection to local modem manually. Then call the other scripts to use
  65. : this connection, but they wouldn't use it.
  66. : 
  67. Ideally you'd like to be able to start Kermit and then send it messages
  68. when you want it to do something.  Unfortunately, Kermit doesn't have a
  69. way to wait for or send messages, so we have to devise a cunning plan.
  70.  
  71. One idea would be to turn your application upside down and let Kermit
  72. control the sequence of events.  For example, it could make the call, log
  73. in, and then run your application with a command-line argument that says
  74. "OK I'm logged in, now what?" and waits for your application to terminate.
  75. At this point it can dispatch based on the return code, perhaps looking in
  76. a prearranged file for instructions.  Repeat as needed.
  77.  
  78. If that's not practical, there is a little-known way of making Kermit wait
  79. for an event:
  80.  
  81.   WAIT <interval-or-clock-time> FILE CREATION <filename>
  82.  
  83. ("help wait" for details.)  This is admittedly a hack, and it would
  84. require the same thing in the other direction, because at this point
  85. Kermit is still running.
  86.  
  87. Thus your application would have to spawn Kermit asynchronously, then
  88. wait for a prearranged file to appear, which Kermit would create just
  89. before doing the WAIT.  Then your application would do whatever it does,
  90. and then when it's ready for Kermit to send a message, it would create
  91. another prearranged file, the one that Kermit is WAITing for.  Obviously,
  92. it would be handy if this file contained the message details.
  93.  
  94. So the Kermit script would go about like this:
  95.  
  96.   Make the call and log in.
  97.   If this failed, return a failure code.
  98.   If it succeeds, create the "I'm logged in" file.
  99.   While true {
  100.       Wait for message file.
  101.       If message file says "Finished" {
  102.           delete the "I'm logged in" file
  103.           Hang up and exit.
  104.       } else {
  105.           send the message.
  106.           delete (or rename) the message file
  107.       }
  108.   }
  109.  
  110. Meanwhile your application would:
  111.  
  112.   Spawn Kermit asynchronously
  113.   Wait for the "I'm logged in" file
  114.   While true {
  115.       Make sure "I'm logged in" file still exists.
  116.       Get a message to send.
  117.       Create message file.
  118.       Wait for message file to disappear.
  119.   }
  120.  
  121. Does this help?  It's not the fashiable TLA du jour but we've never been
  122. particularly concerned with fashion :-)
  123.  
  124. Obviously refinements are possible, such as queueing and various forms of
  125. bulletproofing.
  126.  
  127. - Frank
  128.